1) Release scheduling

Releases should be scheduled for regular intervals: once per month for the main development branches of GeoServer (trunk, 1.3.x, WCS).
For special releases off of the schedule, the PSC must determine for each release:

• The release date. This should be around the same time every month, plus or minus a couple of days.
• The person(s) to make the release. The person(s) must agree to do the release or else the PSC must release themselves. They must be notified well in advance.
• Content of the release.
• Release version number.
• Release off of released versions of GeoTools. If GeoTools can release once a month as well, GeoServer should use that release pending that it passes CITE tests. If not, a previous GeoTools version should be used. Sometimes during release cycles of GeoServer, minor changes will need to be made to GeoTools. In this case it does not make sense to make many small releases of GeoTools. In this case a snapshot release will be sifficient.

Intermediate releases can be made but must follow naming conventions.

2) CITE Tests

All public releases must pass CITE tests.

3) Release Page

There are three sections to the release page:
Stable
Latest
Experimental

Stable: Major, minor, or point releases that have passed through beta stages and been through a full release and tested by the public.
Latest: Major, minor, or point releases that are on a main development branch that has been released before. Does not have to be publically tested. They can be beta versions.
Experimental: Major, minor, or point releases that are not on the main development branch. Milestone releases fit here.

4) Branches

Experimental branches must arrange with the PSC to announce the release and determine an appropriate version number and name. Experimental branches must be released under the Experimental section of the GeoServer download page. Rules for each experimental branch can be discussed by the PSC on a case-by-case basis.

5) Naming conventions

major.minor.point_subpoint
example: 1.3.4_02

Release names can also contain extra information such as RC (Release Candidate), M (Milestone), and should correspond to Maven standards for release names. You must run CITE tests to release.

5.1) Major Release

Major releases do not have to have a backwards compatible API. They are complete feature changes that require dependant projects to migrate towards. You must run CITE tests to release.

5.2) Minor Release

Minor releases must have a backwards compatible API. They can contain major or minor changes and new features to the modules that do not require dependant projects to migrate. You must run CITE tests to release.

5.3) Point Release

Point releases are just bug fixes and very minor changes. The API must be backwards compatible. You must run CITE tests to release.

5.4) Immediate Releases (sub-point releases)

It sometimes happens where a group of developers may need a release out immediately (for conferences, demos, minor fix, etc). These can be named with the sub-point-release version number ( _##, example: 1.3.4_01) and does not have to wait for the PSC to organize it. These releases cannot go under the stable download page and must pass CITE tests to go under the latest download page.
Changes that can take place in the sub_point release are: minor UI fixes, non-programming fixes, minor/trivial bug fixes.

6) Major and Minor releases

Major releases and minor releases should go through release candidates before the official release. During this phase they will be labeled beta on the file names. Once they have gone through a release candidate successfully then they can be released under the stable section of the download page. Until then they are released under the Latest section of the web page.

7) Beta releases

If a release is approaching a minor or major release but is still being tested, beta must be attached to the end of the file name:
1.4.0-RC1_beta
This should be on all release candidates and milestone releases of the major or minor release version.
Note that this should just be on the file names and in the UI, not the version numbers so we don't mess with maven.